Subject: Re: Year 2000 Compliance and the SNA Architecture

From: "jim (j.) cobban" <[email-masked]>
Date: Thu, 22 Aug 1996 00:35:00 -0400

In message "Re: Year 2000 Compliance and the SNA Architecture", 
you write:

>As you say, the Date/Time SV will accomodate to 2155.  If products wrap
>to 00 at 2000, they should be fixed.  I think NetView uses its own 

Unfortunately the architecture currently is very explicit that this SV is
*required* to wrap to zero in 2000.  I am therefore suggesting an amendment
to the architecture that changes the definition of this field.

>time stamp rather than the Date/Time SV anyway, even if it doesn't
>it shouldn't crash.  It could be tolerant enough to 
>recognize any value < 80 as 2000+value if products are found to
>be in error.  I'm pretty sure NetView itself went through a 
>year 2000 review a few years back.

I trust that IBM has made certain that NetView does not crash in the new
millenium (I am not so confident of the NCP, based on actual experience).
However NetView is not the only management application out there.

In the spirit of being precise about what you send and tolerant of what you
receive I suggest that the architecture should specify that the value should
be year-1900, but that to support equipment which may have implemented it as
year mod 100 in accordance with the existing architecture the receiver should
interpret values less than 80 as year-2000.  That gives our customers 83
years to upgrade their old equipment.

Of course once we have dealt with the year 2000 problems we then have to deal
with the wrapping of the UNIX time stamps in 2006, followed by the wrapping
of the S/370 TOD clock in 2024.